Modern enterprise applications are typically implemented as multi-tier systems. Multi-tier systems serve the end-user through a chain of client/server pairs. In general, they include a user interface at the front end, a database management system (DBMS) at the back end, and an application server interposed between the user interface and the database. Depending on the component providing the user interface, an additional middle tier may exist between the user interface and the application server. For example, if the user interface is provided by a web browser, a web server would exist between the web browser and the application server. The web browser would send requests to the web server, and the web server would interact with application data in the database through the application server in order to generate a response to send to the web browser. In this scenario, the web browser and web server form a client/server pair, the web server and application server form another client/server pair, and the application server and DBMS server form yet another client/server pair.
FIG. 1 shows an example of a four-tiered system that includes a user interface tier (2), a web server tier (4), an application server tier (6), and a data tier (8). The user interface tier (2) is the layer of interaction and typically includes a form-like graphical user interface (GUI) displayed by a display component, often a web browser (10). The web server tier (4) includes web components (12) hosted on a web server (14). The web components (12) generate the content displayed by the web browser (10). The application server tier (6) includes application components (16) hosted on an application server (18). The application components (16) model the business rules, typically through interaction with application data. The data tier (8) includes a persistent data store, typically a database management system (DBMS) (22) and a database (i.e., a persistent transactional data store) (20).
The web browser (10) and the web server (14) form a client/server pair. The web server (14) and the application server (18) form another client/server pair. The application server (18) and DBMS (22) form yet another client/server pair. A web component (12) and an application component (16) are in a client/server relationship when the web component (12) (client) uses services of the application component (16) (server) to provide functions to the system. In order for the client and server to collaborate, a contract or interface definition exists, between the client and server that specifies the server methods that can be invoked by the client. When the client and server are in different address spaces, the client uses some form of remote procedure call (RPC) to invoke the server methods. Typically, this involves the client calling into a local stub, which forwards the call to the server.
Multi-tiered enterprise applications, such as described above, are difficult to write because they are inherently complex. The enterprise application developers are expected to be well-versed in many subject areas. The enterprise application developers are expected to be able to understand the business problem and logic to solve the problem, group business logic into transactions, understand how to retrieve and update information in the database, and know how to use multi-processing capabilities to enhance performance of the enterprise application. The enterprise application developers also take into account the type of clients to be supported and the communication protocol to be used between the client and server, the type of server and the enterprise application program interfaces (APIs) supported by the server, and the type of database management system (DBMS) used in managing the database.
In designing and implementing multi-user enterprise applications, application programmers balance data consistency with scalability. In particular, the application programmer ensures that for each transaction the correct data is available for the enterprise application. If application programmers do not consider concurrency control when designing and implementing enterprise application numerous problems can arise. Three typical problems that arise are (i) the lost update problem; (ii) the temporary update problem; and (iii) the incorrect summary problem.
The lost update problem occurs when two concurrent transactions access the same database items and their operations are interleaved in a manner that makes some of the values of the database items incorrect. The temporary update problem occurs when one transaction updates a database item and then the transaction fails for some reason. The updated database item is subsequently accessed by a second transaction before the database item value is changed back to its original value. Finally, the incorrect summary problem occurs when one transaction is calculating an aggregate summary function on a number of records while other transactions are updating some of these records.
The aforementioned problems have been addressed most successfully by using binary read locks and two-phase locks. However, these solutions are not ideal for scalable enterprise applications. Accordingly, the computer industry has moved towards using database systems that have very optimistic read locks or no read lock mechanisms. Alternatively, some database systems have shifted focus from providing read locking to concentrate on resolving write conflicts. In either situation, application programmers using these new database systems are required to insert additional read isolation program logic to enforce read/write consistency that matches the level of read/write isolation that is required by the enterprise application.